Database Mirroring এবং Replication Techniques

SQL Server-এ Database Mirroring এবং Replication দুটি শক্তিশালী প্রযুক্তি যা ডেটাবেসের রেডানডেন্সি, ডেটা প্রাপ্যতা এবং স্কেলেবিলিটি নিশ্চিত করতে ব্যবহৃত হয়। যদিও উভয়ের উদ্দেশ্য ডেটাবেসের কপির উপর নির্ভর করে কাজ করা, তাদের কার্যক্রম এবং প্রয়োগের ক্ষেত্রে কিছু পার্থক্য রয়েছে। এখানে আমরা Database Mirroring এবং Replication এর মৌলিক ধারণা এবং প্রয়োগের পদ্ধতি আলোচনা করব।

1. Database Mirroring

Database Mirroring একটি উচ্চ প্রাপ্যতা (High Availability) এবং ডেটা রিকভারি প্রযুক্তি যা একটি SQL Server ডেটাবেসের পূর্ণাঙ্গ কপি (mirror) তৈরি করে। মিররিং মূলত একটি প্রাথমিক ডেটাবেস (Principal) এবং একটি বা একাধিক সেকেন্ডারি ডেটাবেস (Mirror) তৈরি করে। যদি প্রাথমিক ডেটাবেসটি ডাউন হয়ে যায়, তবে সেকেন্ডারি ডেটাবেসটি স্বয়ংক্রিয়ভাবে সার্ভিস দিতে শুরু করে।

1.1. Database Mirroring এর প্রধান বৈশিষ্ট্য

• ডেটা সুরক্ষা: মূল ডেটাবেসের একটি অনুলিপি (mirror) রাখা হয়, যা প্রাথমিক ডেটাবেসের যে কোনো ত্রুটির কারণে কাজ করতে পারে।
• অটোমেটিক ফেইলওভার: ফেইলওভার-প্রসেসের মাধ্যমে, যদি প্রাথমিক ডেটাবেসে কোনো সমস্যা ঘটে, তবে সেকেন্ডারি ডেটাবেসটি স্বয়ংক্রিয়ভাবে অ্যাক্টিভ হয়ে যায় এবং সার্ভিস প্রদান করতে থাকে।
• প্যারালাল কাজ: মূল ডেটাবেস এবং মিরর ডেটাবেস একসাথে কাজ করতে পারে, তবে ফুল মিররিং কনফিগারেশনে মূল ডেটাবেসের সকল পরিবর্তন মিরর ডেটাবেসে সিঙ্ক্রোনাইজ হয়।

1.2. Database Mirroring Mode

ডেটাবেস মিররিং সাধারণত তিনটি মোডে কাজ করতে পারে:

• Synchronous Mode (High Safety): এখানে, মূল ডেটাবেসের প্রতিটি ট্রানজেকশন মিরর ডেটাবেসে সিঙ্ক্রোনাইজ হতে হয়, অর্থাৎ, মূল ডেটাবেসের পরিবর্তন মিরর ডেটাবেসে সফলভাবে রিপ্লিকেট না হওয়া পর্যন্ত ট্রানজেকশন সম্পন্ন হয় না।
• Asynchronous Mode (High Performance): এখানে, মূল ডেটাবেসের ট্রানজেকশন মিরর ডেটাবেসে পাঠানো হয়, তবে ডেটাবেসটি সফলভাবে সিঙ্ক্রোনাইজ হওয়ার জন্য অপেক্ষা করা হয় না। এটি পারফরম্যান্সের দিক থেকে ভাল, কিন্তু কিছুটা ডেটা ক্ষতির সম্ভাবনা থাকে।
• Witness Mode: এটি সিস্টেমের ফেইলওভার ক্ষমতা অর্জন করতে ব্যবহৃত হয়। যখন প্রাথমিক ডেটাবেস ডাউন হয়ে যায়, তখন উইtnেস দ্বারা স্বয়ংক্রিয় ফেইলওভার ঘটানো হয়।

1.3. Database Mirroring কনফিগারেশন

1. Primary Server এবং Mirror Server তৈরি করুন।
2. Witness Server (যদি প্রয়োজন হয়) কনফিগার করুন।
3. মিররিং কনফিগারেশন করতে T-SQL কমান্ড বা SQL Server Management Studio (SSMS) ব্যবহার করুন।

একটি সাধারণ Database Mirroring কনফিগারেশন:

-- Step 1: Configure principal database
ALTER DATABASE MyDatabase SET PARTNER = 'TCP://PrincipalServer:5022';

-- Step 2: Configure mirror database
ALTER DATABASE MyDatabase SET PARTNER = 'TCP://MirrorServer:5022';

-- Step 3: Configure witness (optional)
ALTER DATABASE MyDatabase SET PARTNER = 'TCP://WitnessServer:5022';

2. Replication

Replication একটি প্রক্রিয়া যা SQL Server ডেটাবেসের ডেটা একাধিক সার্ভারে কপি করে রাখে। এটি মূলত ডেটার ডিসট্রিবিউশন এবং ডেটাবেসের মধ্যে তথ্য সিঙ্ক্রোনাইজেশন নিশ্চিত করার জন্য ব্যবহৃত হয়। Replication সাধারণত ডেটাবেসের মধ্যে তথ্য সিঙ্ক্রোনাইজ করা, স্কেলেবিলিটি বৃদ্ধি এবং ডেটাবেসের পারফরম্যান্স উন্নত করার জন্য ব্যবহৃত হয়।

2.1. Replication এর ধরণ

Replication এর বিভিন্ন ধরণ রয়েছে, যেগুলোর প্রতিটির নিজস্ব ব্যবহার এবং কার্যপ্রণালী রয়েছে:

• Snapshot Replication: এটি একবারে সমস্ত ডেটা কপি করে। প্রতি নির্দিষ্ট সময়ে সমস্ত ডেটাবেসের ডেটা কপি করা হয়। এটি সাধারণত ছোট আকারের ডেটাবেস বা ডেটা যেখানে পরিবর্তন খুব কম ঘটে সেখানে ব্যবহার করা হয়।
• Transactional Replication: এটি একটি খুব দ্রুত এবং কার্যকরী পদ্ধতি, যেখানে ট্রানজেকশনের প্রতিটি পরিবর্তন তৎক্ষণাৎ একাধিক সাবস্ক্রাইবার সার্ভারে কপি হয়। এটি সাধারণত বড় আকারের ডেটাবেস এবং ওয়েব অ্যাপ্লিকেশনগুলির জন্য উপযুক্ত।
• Merge Replication: এটি একটি ডেটাবেসের মধ্যে ডেটা মর্জিংয়ের জন্য ব্যবহৃত হয়, যেখানে একাধিক সাবস্ক্রাইবার এবং পাবলিশারের মধ্যে ডেটা প্রতিস্থাপন এবং ম্যানিপুলেশন করা যায়। এটি মোবাইল অ্যাপ্লিকেশন বা ডেটা লোডের জন্য ব্যবহার করা হয় যেখানে পিরিয়ডিক আপডেট দরকার।

2.2. Replication Architecture

Replication-এ তিনটি মূল উপাদান থাকে:

• Publisher: যেখানে মূল ডেটাবেস অবস্থিত এবং যেখান থেকে ডেটা রেপ্লিকেট করা হয়।
• Subscriber: যেখানে ডেটা কপি (Replicate) হয়ে পৌঁছায় এবং তথ্য ব্যবহার করা হয়।
• Distributor: এটি ডেটা পরিবহণের জন্য মিডিয়েটর হিসেবে কাজ করে, অর্থাৎ, পাবলিশার থেকে সাবস্ক্রাইবারে ডেটা পাঠানোর দায়িত্ব পালন করে।

2.3. Replication কনফিগারেশন

Replication কনফিগার করার জন্য সাধারণত নিম্নলিখিত ধাপগুলি অনুসরণ করা হয়:

1. Publisher এবং Distributor সার্ভার সেটআপ করুন।
2. Subscriber সার্ভার তৈরি করুন।
3. Replication প্রক্রিয়া কনফিগার করুন:
   • পাবলিশার এবং সাবস্ক্রাইবারের মধ্যে ডেটা কপি করার জন্য সঠিক পাথ এবং শর্তাবলী নির্বাচন করুন।

SQL Server Management Studio (SSMS) বা T-SQL ব্যবহার করে এই কনফিগারেশন করা যেতে পারে।

উদাহরণস্বরূপ:

-- Enable publishing and distribution on the Publisher
EXEC sp_adddistributor @distributor = 'PublisherServer', @password = 'password';
EXEC sp_addpublication @publication = 'MyPublication', @publisher = 'PublisherServer', @publication_type = 1;

-- Add subscription
EXEC sp_addsubscription @publication = 'MyPublication', @subscriber = 'SubscriberServer', @destination_db = 'MyDatabase';

3. Database Mirroring এবং Replication এর মধ্যে পার্থক্য

সারাংশ

Database Mirroring এবং Replication উভয়ই ডেটাবেসের বিভিন্ন কপি তৈরি এবং সিঙ্ক্রোনাইজেশন নিশ্চিত করার জন্য ব্যবহৃত হয়, তবে তাদের ব্যবহারের ক্ষেত্রে কিছু পার্থক্য রয়েছে। মিররিং মূলত ডেটার উচ্চ প্রাপ্যতা এবং রিকভারি নিশ্চিত করে, যেখানে রিপ্লিকেশন ডেটার ডিস্ট্রিবিউশন এবং স্কেলেবিলিটি বাড়ানোর জন্য ব্যবহৃত হয়।

Database Mirroring একটি হাই-অ্যাভেইলেবিলিটি (high availability) এবং ডাটা রিকভারি (data recovery) সমাধান যা Microsoft SQL Server-এ উপলব্ধ। এই প্রযুক্তি ব্যবহার করে, একটি ডেটাবেসের পুরো কপি অন্য একটি সার্ভারে (মিরর সার্ভারে) সিঙ্ক্রোনাইজ করা হয়, যাতে মূল ডেটাবেসে কোনো সমস্যা হলে ডেটা দ্রুত পুনরুদ্ধার করা যায়। মূলত, ডেটাবেস মিররিং হল একটি ডেটাবেসের রিয়েল-টাইম কপি তৈরি করার প্রক্রিয়া, যেখানে একটি প্রাইমারি (primary) ডেটাবেস এবং একটি মিরর (mirror) ডেটাবেস থাকে।

ডেটাবেস মিররিং হল একটি উচ্চ স্তরের রেডানডেন্স এবং ফেইলওভার সমাধান যা ডেটাবেস সার্ভারের ক্র্যাশ বা সমস্যা হলে তাত্ক্ষণিকভাবে ডেটাবেস সার্ভারকে পুনরুদ্ধার করার সুবিধা দেয়।

1. Database Mirroring এর প্রধান উপাদানসমূহ

ডেটাবেস মিররিং প্রক্রিয়া সাধারণত তিনটি প্রধান উপাদানের মাধ্যমে পরিচালিত হয়:

1.1. Primary Server (প্রাইমারি সার্ভার)

Primary Server হল সেই সার্ভার যেখানে মূল ডেটাবেস অবস্থান করে। এটি ডেটাবেসের সকল লেখার কাজ (write operations) এবং অন্যান্য রিড/রাইট অ্যাক্সেস পরিচালনা করে। এটি মূল ডেটাবেসের মালিক এবং এই সার্ভার থেকে ডেটার পরিবর্তনগুলো মিরর সার্ভারে পাঠানো হয়।

1.2. Mirror Server (মিরর সার্ভার)

Mirror Server হল সেই সার্ভার যেখানে প্রাইমারি সার্ভারের ডেটাবেসের সিঙ্ক্রোনাইজড কপি রাখা হয়। মিরর সার্ভারটি প্রাইমারি সার্ভারের কোনো সমস্যা হলে তা স্বয়ংক্রিয়ভাবে কার্যকরী হয়ে ওঠে এবং ডেটাবেসের কার্যক্রম চালিয়ে যায়। মিরর সার্ভারে ডেটা রিড অপারেশন সম্ভব হয়, কিন্তু এটি লিখিত পরিবর্তন গ্রহণ করে না (যতক্ষণ না ফেইলওভার ঘটছে)।

1.3. Witness Server (উইটনেস সার্ভার)

Witness Server হল ঐচ্ছিক একটি সার্ভার যা High Availability কনফিগারেশনে ব্যবহৃত হয়। এটি প্রাইমারি এবং মিরর সার্ভারের মধ্যে যোগাযোগের অবস্থান পর্যবেক্ষণ করে এবং একটি automatic failover পরিচালনা করার জন্য নির্বাচিত হয়। উইটনেস সার্ভার ফেইলওভার মেকানিজমের অংশ হিসেবে কাজ করে এবং মিররিং সেশনটি সক্রিয় রাখা সহ আরো কিছু ফিচার সমর্থন করে।

2. Database Mirroring এর কাজের পদ্ধতি

ডেটাবেস মিররিং দুটি প্রধান মুডে কাজ করতে পারে: Synchronous Mode এবং Asynchronous Mode।

2.1. Synchronous Mode (সিঙ্ক্রোনাস মোড)

Synchronous Mode হল সেই মোড যেখানে প্রাইমারি সার্ভারে করা প্রতিটি ডেটাবেস অপারেশন (যেমন ইনসার্ট, আপডেট, ডিলিট) সম্পন্ন হওয়ার পরে তা মিরর সার্ভারে একটি প্রতিলিপি (replica) তৈরি হয়। এই মোডে ডেটা পুরোপুরি সিঙ্ক্রোনাইজ হয়, তবে কিছু বিলম্ব হতে পারে কারণ মিরর সার্ভারকে প্রতিটি ট্রানজেকশন নিশ্চিত করতে হয়।

লাভ:

• এই মোডে ডেটাবেস কনসিস্টেন্সি সর্বাধিক থাকে, কারণ সমস্ত ডেটা সিঙ্ক্রোনাইজ করা হয়।

সীমাবদ্ধতা:

• প্রাইমারি সার্ভারটির পারফরম্যান্সে কিছুটা প্রভাব পড়তে পারে, কারণ প্রতিটি রাইট অপারেশন মিরর সার্ভারে লেখা সম্পন্ন না হওয়া পর্যন্ত প্রক্রিয়া অপেক্ষা করে।

2.2. Asynchronous Mode (অ্যাসিঙ্ক্রোনাস মোড)

Asynchronous Mode হল সেই মোড যেখানে প্রাইমারি সার্ভারে ডেটাবেসের প্রতিটি পরিবর্তন মিরর সার্ভারে লেখা না হওয়া পর্যন্ত অপেক্ষা করা হয় না। এই মোডে, প্রাইমারি সার্ভারে ট্রানজেকশন সম্পন্ন হয়ে গেলে তা মিরর সার্ভারে বিলম্বে পাঠানো হয়।

লাভ:

• সিস্টেমের পারফরম্যান্স উন্নত হয়, কারণ লেখার কাজ প্রাইমারি সার্ভারে দ্রুত ঘটে।

সীমাবদ্ধতা:

• মিরর সার্ভারটির মধ্যে কিছু ডেটা লস হতে পারে, কারণ ডেটা সিঙ্ক্রোনাইজেশন বিলম্বিত হয়।

3. Database Mirroring এর সুবিধাসমূহ

3.1. High Availability (উচ্চ উপলভ্যতা)

ডেটাবেস মিররিং মূলত high availability (HA) সমাধান হিসেবে কাজ করে। ফেইলওভারের মাধ্যমে, ডেটাবেসের ডাউনটাইম কমিয়ে আনা হয় এবং সার্ভারের ক্র্যাশ বা সমস্যার ক্ষেত্রে স্বয়ংক্রিয়ভাবে ডেটাবেসের কপি চালু থাকে।

3.2. Data Redundancy (ডেটা রিডান্ডেন্সি)

ডেটাবেস মিররিং ডেটা রিডান্ডেন্সি নিশ্চিত করে, কারণ একাধিক সার্ভারে ডেটার কপি থাকে। এটি দুর্যোগের পরবর্তী সময়ে ডেটা হারানোর ঝুঁকি কমিয়ে দেয়।

3.3. Fast Failover (দ্রুত ফেইলওভার)

ফেইলওভারের সময়, মিরর সার্ভারটি প্রাইমারি সার্ভারের পরিবর্তে কার্যক্রম পরিচালনা শুরু করে, ফলে ব্যবসায়িক কার্যক্রমে কোনো বড় ধরনের বাধা আসে না। Automatic failover বা manual failover কনফিগারেশন অনুযায়ী এটি কাজ করতে পারে।

3.4. Reduced Downtime (ডাউনটাইম কমানো)

ডেটাবেস মিররিং ব্যবহারে সিস্টেমের ডাউনটাইম কমানো সম্ভব হয়, কারণ সার্ভারের ক্র্যাশ বা অপ্রত্যাশিত সমস্যার পরেও ডেটা ব্যবহারযোগ্য থাকে।

4. Database Mirroring এর সীমাবদ্ধতা

4.1. Limited to SQL Server Editions

ডেটাবেস মিররিং শুধুমাত্র কিছু নির্দিষ্ট SQL Server এডিশনে উপলব্ধ, যেমন SQL Server Enterprise Edition। অন্যান্য এডিশনে কিছু সীমাবদ্ধতা থাকতে পারে।

4.2. No Support for Backup and Restore

ডেটাবেস মিররিং এর মাধ্যমে ব্যাকআপ এবং রিস্টোর করার ব্যবস্থা সরাসরি সমর্থিত নয়। তবে, আপনি মিরর সার্ভারের কপি ব্যবহার করে ডেটা রিকভারি করতে পারেন, কিন্তু এটি একেবারে ব্যাকআপ সমাধান নয়।

4.3. Performance Impact

সিঙ্ক্রোনাস মোড ব্যবহারে পারফরম্যান্স কিছুটা প্রভাবিত হতে পারে, কারণ প্রতিটি রাইট অপারেশন মিরর সার্ভারে সিঙ্ক্রোনাইজ হতে অপেক্ষা করতে হয়।

সারাংশ

Database Mirroring SQL Server এর একটি শক্তিশালী high availability সমাধান যা ডেটাবেসের রিয়েল-টাইম কপি তৈরি করে রাখে এবং প্রয়োজনে দ্রুত ফেইলওভার ব্যবস্থা করে। এর মাধ্যমে আপনি ডেটা হারানোর ঝুঁকি কমিয়ে, ব্যবসায়িক অব্যাহতিপূর্ণতা নিশ্চিত করতে পারেন। তবে, এর কিছু সীমাবদ্ধতাও রয়েছে, যেমন ব্যাকআপ ও রিস্টোরের সীমাবদ্ধতা এবং পারফরম্যান্স ইম্প্যাক্ট।

Replication SQL Server এর একটি গুরুত্বপূর্ণ ফিচার, যা ডেটাবেসের ডেটাকে এক বা একাধিক অবস্থানে কপি (প্রতিলিপি) করে রাখতে সাহায্য করে। এটি মূলত ডেটা শেয়ারিং, একাধিক অবস্থান থেকে ডেটা অ্যাক্সেস, এবং বিভিন্ন সিস্টেমের মধ্যে ডেটা সিঙ্ক্রোনাইজেশনের জন্য ব্যবহৃত হয়। SQL Server এ তিন ধরনের রিপ্লিকেশন ব্যবহৃত হয়: Transactional Replication, Snapshot Replication, এবং Merge Replication। প্রতিটি ধরনের রিপ্লিকেশনের নিজস্ব ব্যবহার এবং সুবিধা রয়েছে, এবং এগুলোর মধ্যে পার্থক্য বুঝে সঠিক টাইপ নির্বাচন করা গুরুত্বপূর্ণ।

1. Transactional Replication

Transactional Replication হল এমন একটি রিপ্লিকেশন মেথড যেখানে ডেটাবেসে যতটুকু পরিবর্তন (insert, update, delete) হয়, সেগুলোর প্রতিটি ট্রানজেকশন মূল সার্ভার থেকে সাবস্ক্রাইবার সার্ভারে দ্রুত এবং সঠিকভাবে সিঙ্ক্রোনাইজ হয়ে যায়। এই ধরনের রিপ্লিকেশন মূলত ব্যবহার করা হয় যখন ডেটা রিয়েল-টাইম সিঙ্ক্রোনাইজেশন প্রয়োজন এবং ডেটা পরিবর্তনের পরিমাণ বেশি থাকে।

1.1. কিভাবে কাজ করে?

• Publisher: মূল ডেটাবেস যেখান থেকে ডেটা কপি (replicate) করা হয়।
• Subscriber: যেখানে ডেটার কপি রাখা হয়, এবং এটি মূল ডেটাবেসের সঙ্গে সিঙ্ক্রোনাইজ থাকে।
• Distributor: একটি মধ্যবর্তী সার্ভার যা Publisher এবং Subscriber এর মধ্যে ডেটা বিতরণ (distribute) করে।

Transactional Replication নিশ্চিত করে যে সব ধরনের ডেটা পরিবর্তন প্রতি সেকেন্ডে (real-time) সাবস্ক্রাইবারে রেপ্লিকেট হবে। ডেটার প্রতি একটি ট্রানজেকশন লগ রাখা হয় এবং এটি সম্পূর্ণ ট্রানজেকশনকে সাবস্ক্রাইবারের কাছে পাঠানো হয়।

1.2. সুবিধা

• Real-time Synchronization: ডেটার মধ্যে কোনও বিলম্ব ছাড়া দ্রুত সিঙ্ক্রোনাইজেশন।
• High Throughput: যখন পরিবর্তন বেশি হয়, তখন এটি কার্যকরী থাকে।

1.3. ব্যবহার

Transactional Replication ব্যবহার করা হয় যেখানে ডেটার সঠিকতা এবং রিয়েল-টাইম আপডেট গুরুত্বপূর্ণ। উদাহরণস্বরূপ, ফাইনান্সিয়াল অ্যাপ্লিকেশন, ইনভয়েস সিস্টেম, অথবা অন্যান্য সিস্টেম যেখানে দ্রুত এবং নির্ভুল ডেটা পরিবর্তন প্রয়োজন।

2. Snapshot Replication

Snapshot Replication হল এমন একটি রিপ্লিকেশন মেথড, যেখানে নির্দিষ্ট সময় পর পর পুরো ডেটাবেসের একটি স্ন্যাপশট (snapshot) তৈরি করা হয় এবং এটি সাবস্ক্রাইবারে পাঠানো হয়। অর্থাৎ, কোনো ধরনের ট্রানজেকশন লগের পরিবর্তন ট্র্যাক করা হয় না, বরং একটি স্থির ডেটার কপি তৈরি করা হয় এবং সেটি সাবস্ক্রাইবারে পাঠানো হয়।

2.1. কিভাবে কাজ করে?

Snapshot Replication কাজ করে একদম একটি "ছবির মতো" (snapshot) কপি তৈরি করে। নির্দিষ্ট সময়ে (যেমন দৈনিক বা সাপ্তাহিক) একটি সম্পূর্ণ কপি সাবস্ক্রাইবারে পাঠানো হয়। এই ধরনের রিপ্লিকেশন এমন অবস্থায় ব্যবহৃত হয় যেখানে ডেটার মধ্যে বড় পরিবর্তন না হলেও, পুরো ডেটা আবার একত্রে প্রেরণ করা প্রয়োজন।

2.2. সুবিধা

• সহজ এবং দ্রুত সেটআপ: Snapshot Replication সহজেই সেটআপ করা যায় এবং রক্ষণাবেক্ষণ করা সহজ।
• ডেটার অল্প পরিবর্তন: যদি ডেটায় খুব বেশি পরিবর্তন না ঘটে, তবে এটি কার্যকরী হতে পারে।
• নির্দিষ্ট সময়ে একযোগে আপডেট: সাবস্ক্রাইবারদের একটি নির্দিষ্ট সময়ে স্ন্যাপশট পাঠানো হয়, যা অন্যান্য সিস্টেমের সঙ্গে সিঙ্ক্রোনাইজ থাকতে সাহায্য করে।

2.3. ব্যবহার

Snapshot Replication সাধারণত তখন ব্যবহৃত হয় যখন ডেটার মধ্যে কম পরিবর্তন ঘটে এবং সিস্টেমে শুধুমাত্র একবারের স্ন্যাপশট প্রয়োজন হয়। উদাহরণস্বরূপ, প্রোডাক্ট ক্যাটালগ, সিস্টেম কনফিগারেশন ডেটা, বা অন্যান্য স্থির ডেটা যেখানে ধারাবাহিক আপডেট প্রয়োজন নেই।

3. Merge Replication

Merge Replication এমন একটি রিপ্লিকেশন মেথড যেখানে উভয় (Publisher এবং Subscriber) দিকে ডেটার পরিবর্তন হতে পারে, এবং এই পরিবর্তনগুলো একে অপরের সঙ্গে সিঙ্ক্রোনাইজ করা হয়। এটি সাধারণত ব্যবহৃত হয় যেখানে ডেটা উভয় দিক থেকে পরিবর্তিত হতে পারে এবং সাবস্ক্রাইবারের কাছে সামান্য বিলম্ব সহ আপডেট প্রয়োজন।

3.1. কিভাবে কাজ করে?

• Publisher: মূল ডেটাবেস যেখান থেকে ডেটা প্রকাশিত হয়।
• Subscriber: যেখান থেকে ডেটা গ্রহণ করা হয় এবং সেখানে ডেটা পরিবর্তন হতে পারে।
• Conflict Resolution: যদি Publisher এবং Subscriber উভয় জায়গায় একই ডেটা পরিবর্তিত হয়, তবে এটি কনফ্লিক্ট সৃষ্টি করে, এবং conflict resolution এর মাধ্যমে সিস্টেম তা সমাধান করে।

3.2. সুবিধা

• Bidirectional Data Updates: উভয় দিক থেকেই ডেটা আপডেট করার সুবিধা।
• Conflict Resolution: কনফ্লিক্টের ক্ষেত্রে স্বয়ংক্রিয়ভাবে সমাধান করা হয়।
• Flexible Data Synchronization: যেকোনো দিকে ডেটার পরিবর্তন হতে পারে এবং তা সিঙ্ক্রোনাইজ করা যায়।

3.3. ব্যবহার

Merge Replication ব্যবহার করা হয় যখন সিস্টেমের মধ্যে উভয় দিক থেকেই ডেটার পরিবর্তন হতে পারে, যেমন distributed systems, offline systems (যেগুলি মাঝে মাঝে সিঙ্ক্রোনাইজ করা হয়), এবং যেখানে ডেটা দুইটি বা তার বেশি জায়গা থেকে সংশোধিত হতে পারে। উদাহরণস্বরূপ, একটি মোবাইল অ্যাপ্লিকেশন যেখানে ব্যবহারকারী ডেটা এডিট করে, এবং পরে সেটি সার্ভারে আপডেট করতে হয়।

4. উপসংহার

Transactional, Snapshot, এবং Merge Replication প্রতিটি নির্দিষ্ট প্রয়োজনে ব্যবহার করা হয়।

• Transactional Replication ব্যবহৃত হয় যখন দ্রুত এবং নির্ভুল ডেটা সিঙ্ক্রোনাইজেশন প্রয়োজন।
• Snapshot Replication ব্যবহৃত হয় যখন ডেটায় বড় পরিবর্তন না ঘটে এবং পুরো ডেটার একটি স্ন্যাপশট প্রয়োজন হয়।
• Merge Replication ব্যবহৃত হয় যখন উভয় দিক থেকে ডেটার পরিবর্তন হয় এবং ডেটা সিঙ্ক্রোনাইজ করতে কনফ্লিক্ট রেজল্যুশন প্রয়োজন।

সঠিক রিপ্লিকেশন মেথড নির্বাচন করলে ডেটাবেসের পারফরম্যান্স এবং ডেটা অ্যাভেইলেবিলিটি সর্বাধিক নিশ্চিত করা যায়।

High Availability (HA) এবং Disaster Recovery (DR) হলো ডেটাবেস সিস্টেমের জন্য অত্যন্ত গুরুত্বপূর্ণ কৌশল যা সিস্টেমের অটুটতা এবং ডেটার সুরক্ষা নিশ্চিত করতে ব্যবহৃত হয়। এগুলি SQL Server এবং অন্যান্য ডেটাবেস সিস্টেমে প্রাসঙ্গিক, যাতে ডেটাবেস সার্ভার বা সিস্টেমে কোনো ধরনের বিপর্যয় ঘটলে পরিষেবা বা ডেটা দ্রুত পুনরুদ্ধার করা যায়। এই কৌশলগুলো ব্যবহৃত হয় ডাউনটাইম কমানোর এবং ব্যবসার ক্রমাগত অপারেশন নিশ্চিত করার জন্য।

1. High Availability (HA) Techniques

High Availability কৌশলগুলি ব্যবহার করে নিশ্চিত করা হয় যে একটি ডেটাবেস সার্ভার কখনও অফলাইন হবে না বা একাধিক সিস্টেমে সিস্টেমের কাজ চলতে থাকবে। এটি বিশেষত বড় প্রতিষ্ঠানের জন্য অত্যন্ত গুরুত্বপূর্ণ যেখানে কোনো ডেটাবেস সিস্টেমের ডাউনটাইম ব্যবসার জন্য ক্ষতিকর হতে পারে।

1.1. Always On Availability Groups

Always On Availability Groups হল SQL Server এর একটি HA ফিচার যা ডেটাবেসগুলোর গ্রুপ তৈরি করে এবং সেগুলিকে একাধিক সার্ভারে সিঙ্ক্রোনাইজ করে রাখে। এতে একটি প্রাইমারি সার্ভারের সাথে একাধিক সেকেন্ডারি সার্ভার থাকে। যখন প্রাইমারি সার্ভার ডাউন হয়, তখন সেকেন্ডারি সার্ভার থেকে পরিষেবা চালু করা যায়।

• Automatic Failover: যদি প্রাইমারি সার্ভার অকেজো হয়ে যায়, তবে সেকেন্ডারি সার্ভারে অটোমেটিক্যালি ফেইলওভার ঘটে।
• Active Data Syncing: সেকেন্ডারি সার্ভারে ডেটা নিয়মিতভাবে সিঙ্ক্রোনাইজ করা হয়।

1.2. SQL Server Clustering

SQL Server Failover Clustering একটি HA সমাধান যা একাধিক সার্ভারকে একটি ক্লাস্টারে একত্রিত করে, যেখানে একাধিক SQL Server ইনস্ট্যান্সে ডেটাবেস হোস্ট করা হয়। যদি কোনো এক্সট্রা নোডে সমস্যা হয়, অন্য সার্ভারে ডেটাবেসের পরিষেবা সরানো হয়।

• Shared Storage: ক্লাস্টারড সার্ভারের মধ্যে সাধারণ স্টোরেজ শেয়ার করা হয়।
• Clustered Failover: কোনো সার্ভার ডাউন হলে অন্য সার্ভারে তাত্ক্ষণিকভাবে পরিষেবা চলে যায়।

1.3. Database Mirroring

Database Mirroring হল একটি HA প্রযুক্তি যেখানে একটি প্রাইমারি ডেটাবেস এবং একটি মিরর ডেটাবেস তৈরি হয়। যখন প্রাইমারি ডেটাবেসে কোনো সমস্যা দেখা দেয়, মিরর ডেটাবেস থেকে ফেইলওভার করা সম্ভব হয়।

• Synchronous Mirroring: প্রতিটি ট্রানজেকশন মিরর ডেটাবেসে রাইট হওয়ার সাথে সাথে নিশ্চিত করা হয়।
• Asynchronous Mirroring: কিছু দেরিতে মিরর ডেটাবেসে ট্রানজেকশন লেখা হয়, যা উচ্চ পারফরম্যান্সের জন্য উপযুক্ত।

2. Disaster Recovery (DR) Techniques

Disaster Recovery কৌশলগুলি ব্যবহৃত হয় এমন পরিস্থিতিতে যখন সমস্ত সার্ভার বা ডেটাবেস সিস্টেম সম্পূর্ণভাবে বিপর্যস্ত হয়ে পড়ে। এই কৌশলগুলি নিশ্চিত করে যে ডেটা নিরাপদ এবং দ্রুত পুনরুদ্ধারযোগ্য।

2.1. Database Backups

Database Backups হল DR কৌশলের একটি মৌলিক অংশ। নিয়মিত ব্যাকআপ নেওয়া হয় যাতে কোনো বিপর্যয়ের সময় সিস্টেমটি পুনরুদ্ধার করা যায়। ব্যাকআপের ধরনগুলো হলো:

• Full Backup: পুরো ডেটাবেসের ব্যাকআপ, যা সব ডেটা একত্রে সঞ্চিত করে।
• Differential Backup: সর্বশেষ পূর্ণ ব্যাকআপের পরবর্তী পরিবর্তনসমূহের ব্যাকআপ।
• Transaction Log Backup: ট্রানজেকশন লগের ব্যাকআপ, যা ডেটাবেসের সকল পরিবর্তন লগ করে রাখে।

2.2. Log Shipping

Log Shipping একটি DR কৌশল যা SQL Server এর মধ্যে ট্রানজেকশন লগ ফাইলের নিয়মিত ব্যাকআপ নেয় এবং সেগুলি অন্য সার্ভারে পুনঃসংকলন করে। এটি একটি সেকেন্ডারি সার্ভারে ডেটাবেস সিঙ্ক্রোনাইজ করে রাখে যাতে প্রধান সার্ভার ডাউন হলে ডেটা দ্রুত পুনরুদ্ধার করা যায়।

• Primary and Secondary Servers: একটি প্রাইমারি এবং একাধিক সেকেন্ডারি সার্ভার থাকে।
• Transaction Log Backup and Restore: প্রতিটি ট্রানজেকশন লগ ফাইল নিয়মিতভাবে ব্যাকআপ এবং রিস্টোর করা হয়।

2.3. Geo-Replication

Geo-Replication হল একটি DR কৌশল যেখানে একটি ডেটাবেসের অনুলিপি বিভিন্ন ভৌগোলিক অবস্থানে রাখা হয়। এতে বিপর্যয়ের সময়ে সিস্টেমের কাজ অন্য একটি ভৌগোলিক অবস্থানে সরানো যায়। এটি বিশেষ করে ক্লাউড এনভায়রনমেন্টে ব্যবহার করা হয়।

• Multi-Region Replication: ডেটাবেস একাধিক অঞ্চলে রিপ্লিকেট করা হয়, যাতে বিপর্যয়ের সময়ে অন্য অঞ্চলের ডেটাবেস থেকে সেবা চালু রাখা যায়।

2.4. Point-in-Time Recovery

Point-in-Time Recovery হল একটি কৌশল যা আপনাকে কোনো নির্দিষ্ট সময়ের পূর্ববর্তী অবস্থায় ডেটাবেস পুনরুদ্ধার করতে সক্ষম করে। এটি বিশেষ করে ট্রানজেকশন লগের সাহায্যে কাজ করে এবং ডেটাবেসের সঠিক অবস্থানে ফিরে যাওয়ার সুবিধা দেয়।

• Transaction Log Restoration: পূর্ববর্তী ট্রানজেকশন লগ পুনরুদ্ধার করে নির্দিষ্ট পয়েন্টে ডেটাবেস ফিরিয়ে আনা যায়।
• Data Loss Minimization: পয়েন্ট-ইন-টাইম রিকভারি ডেটা লসকে সর্বনিম্নে রাখে।

3. High Availability এবং Disaster Recovery এর মধ্যে পার্থক্য

• High Availability (HA): এটি সিস্টেমের কাজ চালু রাখার জন্য ব্যবহৃত হয়, যাতে কোনো ধরনের ডাউনটাইম না থাকে। HA কৌশলগুলি দ্রুত ফেইলওভার এবং পুনরুদ্ধারের সুবিধা দেয়।
• Disaster Recovery (DR): এটি মূলত ডেটা এবং সিস্টেম পুনরুদ্ধারের জন্য ব্যবহৃত হয় যখন কোনো বড় বিপর্যয় ঘটে, যেমন সার্ভার ক্র্যাশ বা প্রাকৃতিক দুর্যোগ। DR কৌশলগুলি ডেটা নিরাপত্তা এবং দীর্ঘমেয়াদি পুনরুদ্ধার ফোকাস করে।

এই High Availability এবং Disaster Recovery কৌশলগুলি একত্রে ডেটাবেস সিস্টেমের প্রাপ্যতা এবং সুরক্ষা নিশ্চিত করে, এবং ব্যাবসায়িক ক্রিয়াকলাপের ধারাবাহিকতা বজায় রাখে।

Log Shipping এবং Failover Cluster Management দুটি অত্যন্ত গুরুত্বপূর্ণ ডেটাবেস রিপ্লিকেশন এবং ডেটা রিকভারি কৌশল, যা ডেটাবেসের উচ্চ প্রবণতা, রিলায়েবিলিটি, এবং ডিসাস্টার রিকভারি নিশ্চিত করতে ব্যবহৃত হয়। এগুলো মূলত SQL Server বা অন্যান্য ডেটাবেস ম্যানেজমেন্ট সিস্টেমে ডেটার নিরাপত্তা এবং অখণ্ডতা নিশ্চিত করতে গুরুত্বপূর্ণ ভূমিকা পালন করে।

1. Log Shipping

Log Shipping হল একটি ডেটাবেস রিপ্লিকেশন কৌশল যা ডেটাবেসের transaction logs কপি এবং একাধিক সার্ভারে প্রেরণ করে। এটি ডেটাবেসের ডিসাস্টার রিকভারি (disaster recovery) পরিকল্পনার একটি অংশ হিসেবে ব্যবহৃত হয়, যা নিশ্চিত করে যে প্রাইমারি সার্ভারের ডেটা সেকেন্ডারি সার্ভারে সিঙ্ক্রোনাইজ থাকবে এবং প্রাইমারি সার্ভারে কোনো সমস্যা হলে সেকেন্ডারি সার্ভার ব্যবহার করা যাবে।

Log Shipping এর মূল ধারণা:

• Primary Server: মূল সার্ভার, যেখানে ডেটাবেসের লেখাগুলি তৈরি হয়।
• Secondary Server: এক বা একাধিক রিড-অনলি সার্ভার যা প্রাইমারি সার্ভারের লগ ফাইল নিয়ে সিঙ্ক্রোনাইজ হয় এবং ডেটা রিকভারি বা রিপোর্টিং-এর জন্য ব্যবহৃত হয়।
• Standby Server: সেকেন্ডারি সার্ভার যদি প্রাইমারি সার্ভারের ব্যর্থতার পরও কার্যকরী থাকে, তবে এটি স্ট্যান্ডবাই সার্ভার হিসেবে ব্যবহৃত হতে পারে।

Log Shipping-এর কাজ করার পদ্ধতি:

1. Transaction Log Backup: প্রাইমারি সার্ভারে ডেটাবেসের ট্রানজেকশন লগের ব্যাকআপ নেওয়া হয়।
2. Log Copy: ট্রানজেকশন লগের ব্যাকআপটি সেকেন্ডারি সার্ভারে কপি করা হয়।
3. Log Restore: সেকেন্ডারি সার্ভারে ট্রানজেকশন লগটি রিস্টোর করা হয়, যাতে এটি প্রাইমারি সার্ভারের ডেটার সাথে সিঙ্ক্রোনাইজ থাকে।

Log Shipping-এর সুবিধা:

• Disaster Recovery: প্রাইমারি সার্ভারে কোনো সমস্যা হলে সেকেন্ডারি সার্ভারকে সহজেই পিভট করা যায়।
• High Availability: সেকেন্ডারি সার্ভারে ডেটার সর্বশেষ অবস্থান পাওয়া যায়।
• Data Integrity: ট্রানজেকশন লগের মাধ্যমে ডেটা ক্ষতি কমানো যায় এবং পুনরুদ্ধারের সময় সঠিকতা নিশ্চিত করা যায়।

Log Shipping-এ ব্যবহৃত কিছু SQL কমান্ড:

• Backup Transaction Log:

  BACKUP LOG [DatabaseName]
  TO DISK = 'C:\Backups\TransactionLogs\log_backup.trn';
  

• Restore Transaction Log on Secondary Server:

  RESTORE LOG [DatabaseName]
  FROM DISK = 'C:\Backups\TransactionLogs\log_backup.trn'
  WITH NORECOVERY;
  

Log Shipping-এর চ্যালেঞ্জ:

• Data Latency: এটি বাস্তব সময়ে ডেটা সিঙ্ক্রোনাইজ না হওয়ার কারণে কিছু ডেটা দেরিতে রিফ্লেক্ট হতে পারে।
• Manual Failover: প্রাইমারি সার্ভার ডাউন হলে, সেকেন্ডারি সার্ভারকে ম্যানুয়ালি পিভট বা স্ট্যান্ডবাই মোডে আনা হয়।

2. Failover Cluster Management

Failover Clustering হল একটি হাই-এভেইলেবিলিটি কৌশল যা সার্ভারের একাধিক নোডকে যুক্ত করে এবং একটি সমস্যা বা ব্যর্থতার ঘটনার পর অন্য নোডে স্বয়ংক্রিয়ভাবে সিস্টেমের কাজ চালিয়ে যেতে সক্ষম হয়। এটি মূলত ডেটাবেসের সার্ভার নিরবচ্ছিন্নভাবে চলমান রাখতে সাহায্য করে।

Failover Cluster এর মূল ধারণা:

• Clustered Servers: একাধিক সার্ভার (নোড) যা হোস্টিং ডেটাবেস সার্ভিসের জন্য একসাথে কাজ করে।
• Active Node: এটি সেই নোড যা বর্তমানে কাজ করছে, অর্থাৎ সকল ডেটাবেস সার্ভিসের প্রাথমিক দায়িত্বে রয়েছে।
• Passive Node: এটি একটি ব্যাকআপ নোড যা প্রাইমারি নোডের সমস্যা হলে সক্রিয় হয়।
• Quorum: কনফিগারেশন নিশ্চিত করে যে ক্লাস্টারে একটি নির্দিষ্ট সংখ্যক নোড সক্রিয় থাকে, যাতে ডিসি (Data Consistency) বজায় থাকে।

Failover Clustering এর কাজ করার পদ্ধতি:

1. Cluster Configuration: একাধিক সার্ভার নোডকে ক্লাস্টারে যুক্ত করা হয়।
2. Active Node Assignment: ক্লাস্টারের এক বা একাধিক সার্ভারে ডেটাবেস রান করে, এবং একটি নোডই সক্রিয় থাকে।
3. Health Monitoring: ক্লাস্টার কনফিগারেশন স্বয়ংক্রিয়ভাবে সক্রিয় নোডের স্বাস্থ্য পরীক্ষা করে। যদি কোনো নোডে সমস্যা হয়, তবে এটি তাত্ক্ষণিকভাবে অন্য নোডে পিভট করে।
4. Failover Process: প্রাইমারি নোডে কোনো সমস্যা হলে, ক্লাস্টারটি সেকেন্ডারি নোডে ডেটাবেস ট্রান্সফার করে, যাতে সিস্টেমের কাজ চালু থাকে।

Failover Cluster এর সুবিধা:

• High Availability: ক্লাস্টার কনফিগারেশন সার্ভারের ব্যর্থতার পরও ডেটাবেস সার্ভিস চালু রাখতে সহায়তা করে।
• Automatic Failover: একটি নোড ব্যর্থ হলে অন্য নোডে ট্রান্সফার হওয়া নিশ্চিত করে।
• Data Protection: একাধিক সার্ভারে ডেটা স্টোর করা থাকে, তাই হারানো ডেটা বা সিস্টেম ডাউনটাইমের সম্ভাবনা কম থাকে।

Failover Clustering কনফিগারেশন:

SQL Server failover cluster তৈরি করতে SQL Server setup-এ SQL Server Failover Cluster Instance নির্বাচন করতে হয়।

Log Shipping এবং Failover Cluster Management এর মধ্যে পার্থক্য:

সারাংশ:

• Log Shipping একটি ভাল ডিসাস্টার রিকভারি কৌশল, যেখানে Failover Clustering ডেটাবেসের হাই-এভেইলেবিলিটি নিশ্চিত করে।
• Log Shipping ব্যাকআপ এবং সেকেন্ডারি সার্ভারে ডেটা সিঙ্ক্রোনাইজের মাধ্যমে কাজ করে, যেখানে Failover Clustering পুরো ক্লাস্টার ডাউনটাইমের ঝুঁকি কমিয়ে দেয় স্বয়ংক্রিয় failover দ্বারা।